4.3 Clip Validation

As hinted above, the graphics pipe mapping is not always immediately validated when a process faults on a pipe access.

Each rendering node has a clip resource which is either valid or invalid. When valid, the graphics kernel driver has up-to-date window clipping parameters in the pane cache for the window that can be loaded into the rendering node's graphics hardware context (either a set of clip rectangles or a CID value to use). When the clip resource is valid and there is no other reason for the pipe to be invalid, the kernel graphics page fault handler validates the graphics pipe pages after loading the correct clipping information into the graphics hardware context.

 

 

Figure 2: RRM clip validation assisted by the X server.

If the rendering node's clip resource is invalid, the faulting process is suspended and a clip validate message is sent to the X server. The X server receives the message through the shmiq and issues a board manager reserved ``clip validate'' ioctl to the graphics driver informing the kernel of the correct clipping parameters for the window. When the pane cache entry for the window is updated with the new clip information, then any processes waiting for the clip resource of the window to be validated are awakened. The result is that a graphics process can asynchronously have its clip updated without any knowledge on the part of the process. An example of the clip validation process is described in Figure 2.

Clip resources are possibly invalidated by the X server whenever the window tree is manipulated by X window management operations. The X server tracks which windows are being used for direct rendering, and if the clips of any of these windows change the X server uses a board manager reserved ``clip invalidate'' ioctl to tell the kernel to invalidate the clip resource of any rendering nodes bound to the windows. The invalidation of a clip happens asynchronously to the direct rendering program and can happen at any time the X server needs it to. The next time a direct rendering program attempts to render to the window, the clip validation process ensures a new, correct clip is loaded into the direct renderer's graphics hardware context.

The other reason the clip resource of a window might be invalidated is if too many windows that need CIDs assigned to them are being directly rendered to. Remember there are a limited number of CIDs in the hardware. The X server can virtualize clips by invalidating the clip of one window assigned a CID, reusing the CID by repainting another window with the newly freed CID, and then validating the clip of a window and assigning it the newly reassigned CID. The X server makes no attempt to handle thrashing or starvation due to repeated CID invalidations and validations, but in practice, because most windows use clip rectangles, CID thrashing is not a problem.

Notice that clip validation happens lazily. Not until a direct renderer actually touches the pipe does a clip validation begin. Often when clips on the screen change, they change repeatedly (a window manager using opaque move is a good example of this). So it makes sense to validate clips only on demand.

The pane cache minimizes clip validation costs when an OpenGL process repeatedly binds and rebinds to different windows (an operation expected to be common for OpenGL programs). A rendering node can be bound to a previously bound window, and if the window is still in the pane cache and the clip is still valid, immediately have a valid clip resource.